Présentation du testbed Emulab

I Quest-ce qu'un testbed ?

Un testbed, ou plateforme de test, est un environnement dédié aux expérimentations. Je vais ici vous présenter l'un de ces testbeds, que j'ai eu l'occasion d'utiliser durant un stage de recherche à l'ENS. Cette plateforme, nommée Emulab, est un testbed réseau. Elle permet de réserver un certain nombre de machines et de s'en servir, notamment pour des expériences réseau. Un accès distant est donné vers ses machines afin de les manipuler à notre guise. Le choix de cette plateforme plutôt qu'une autre a été fait à la suite de stages précédents, visant à sélectionner le testbed le plus adéquat pour les expérimentations que nous avions à mener. L'une des particularités de ce testbed est qu'il propose des configurations de réseau sans fils. Nos expériences étant exclusivement basée sur le comportement d'une topologie WiFi multi-sauts, cette fonctionnalité sera le coeur de cet article. Je vais essayer de vous présenter cette plateforme, son utilisation ainsi que les avantages et inconvénients de l'utilisation du testbed plutôt que d'un set-up "maison" pour effectuer des expérimentations.

II Présentation de la plateforme

Je vais essayer ici de vous présenter les principales fonctionnalités de la pateforme Emulab. Cependant il est à noter que le site dispose d'un wiki assez bien fourni ici. Il présente l'ensemble des fonctionnalités de la plateforme et donne des exemples d'utilisations. Cette plateforme est donc assez simple d'accès, car l'utilisateur peut rapidement implémenter l'expérience dont il a besoin. De plus, les scripts décrivant l'architecture voulu par l'utilisateur sont très proches des scripts utilisés dans le simulateur NS. Mais nous aborderons cependant le sujet des scripts plus en détail par la suite.

Fonctionalitées

Emulab propose un certain nombre de fonctions intéressantes. Je ne vais faire ici qu'un bref inventaire des fonctions proposées, si cela vous intéresse, je vous renvois vers le wiki qui présente cela : ici

Accès root au machines : Une fois les machines réservées, un acces SSH est possible grâce à une IP qui est fourni par machine. Une fois de l'on a accédé à une machine, on a un total contrôle sur celle-ci. En effet, la plateforme nous donne un accès root et nous permet donc, entre autre, de modifier la configuration réseau des machines. Il faut donc faire particulièrement attention à ne pas modifier la configuration de l'interface qui relie la machine à l'extérieur. Comment ça ? Non ça sent pas le vécu ... ^_^'

Choix du système d'exploitation : La plateforme permet un choix assez large d'OS. Pour en avoir une liste c'est par là que ça se passe. Emulab ne fait pas que proposer un grand nombre d'images, il propose même d'effectuer des expériences sur des machines tournant sous Windows. Si, si c'est vrai regardez, c'est là

Choix du matériel : Pour effectuer les expérimentations, un utilisateur peut avoir envie que les machines utilisées répondent à des critères spécifiques. Emulab propose toute une liste de configurations matérielles disponible ici.

Déploiement de noeud virtuel : Il est également possible de déployer des noeuds virtuels. Ce type de noeud est utile quand le nombre de noeuds physiques disponible sur Emulab n'est pas suffisant, que se soit dû à l'activité-même de la plateforme (trop d'expériences en cours pour avoir la place d'effectuer la sienne) ou parce que les besoins de l'expérience sont trop grands. En revanche, je n'ai pas eu l'occasion d'utiliser cette fonctionnalité durant mon stage, donc si vous voulez en savoir plus, je vous laisse un lien vers la documentation du site concernant ce point-là. Et le lien est .... ici ! Eucalyptus : Emulab offre aussi la possibilité de mettre en place un Cloud Eucalyptus. Mais je ne me suis pas attardé sur cette feature, n'étant pas du tout intéressé par cette dernière. Voici donc le lien vers la documentation expliquant comment déployer Eucalyptus. https://wiki.emulab.net/wiki/eucalyptus

Particularité : le WiFi

Si nous avons choisi cette plateforme plutôt qu'une autre, c'est parce qu'elle propose l'utilisation de noeud WiFi, ainsi que le fait, comme dit précédement, qu'il soit assez simple de commencer une expérimentation grâce aux exemples proposés dans la documentation. Dans la suite de ce blog, je vais donc surtout parler de la partie WiFi d'Emulab.

III Utilisation de la plateforme

Dans cette partie je vais brièvement vous présenter comment parvenir à obtenir des résultats avec Emulab. Puis, dans les deux dernières sections, je vous expliquerai quels sont, selon moi, les avantages et inconvénients d'utiliser ce genre de système plutôt que concevoir soi-même son environnement d'expérimentations.

Carte des noeuds

Pour commencer une expérience, il est bon de s'intéresser aux noeuds qui sont disponibles. Tout du moins, pour l'utilisation de noeuds physiques, car, quant aux noeuds virtuels, je ne sais pas vraiment comment ça se passe. En tout cas pour connaître les noeuds qui sont disponibles il est possible d'en avoir la liste ici. Pour les noeuds wifi en revanche, il faut s'assurer que les machines soient disponibles, mais aussi qu'elles soient dans de bonnes dispositions géographiques. Ce serait dommage que les machines dont on ait besoin soient effectivement disponibles, mais qu'elles ne soient pas capable de communiquer à cause de la distance les séparant ... Quoi ? Ca sent encore le vécu ? .... :D
Mais il y a tout de même une carte permettant de voir rapidement s'il sera possible de déployer l'expérience ou pas.



Il faut juste savoir que cette carte n'est pas disponible si on ne possède pas de compte sur la plateforme. Profitez-en bien, tout le monde n'a pas la chance de voir ça tous les jours ^^

Exemple d'un script

Ici nous allons regarder un exemple de script servant sur Emulab. La description de l'architecture réseau que l'on souhaite réserver se fait via un script. Le langage utilisé est TCL et les scripts ressemblent fortement à ceux utilisés dans le simulateur NS. Attention toutefois, ils ne sont pas interopérables. De légères modifications doivent être faites, par exemple le choix de l'OS. En effet, avec NS il n'est pas nécessaire de choisir quel OS sera installé sur les machines.
Exemple de script ayant servi durant mon expérience à l'ENS. L'architecture requise était la suivante : trois noeuds communicants entre noeuds avec une topologie de chaîne. C'est à dire que le premier noeud ne peut communiquer avec le troisième que s'il passe par le deuxième. De plus, un quatrième noeud est nécessaire pour monitorer le trafic car, pour récupérer les informations qui nous intéressaient, il était nécessaire qu'un noeud ait une carte réseau configurée en mode monitor. Ces quatre machines utilisaient exclusivement du WiFi pour communiquer.
######
###### Topologie de 3 noeud constituant un réseau LAN WiFi
###### Avec un quatrième noeud jouant le rôle de moniteur
######

source tb_compat.tcl
set ns [new Simulator]

# Allocatation des noeud et choix du type de noeud
set nodew1 [$ns node]
tb-set-hardware $nodew1 pc2400w

set nodew2 [$ns node]
tb-set-hardware $nodew2 pc2400w

set nodew3 [$ns node]
tb-set-hardware $nodew3 pc2400w

###nodew4 est un moniteur
set nodew4 [$ns node]
tb-set-hardware $nodew4 pc2400w


## Créaction du LAN contenant les trois noeud de la chaîne
set lan0 [$ns make-lan "$nodew1 $nodew2 $nodew3 " 54Mb 0ms]


# Choix du protocole sans-fil pour le réseau
tb-set-lan-protocol $lan0 "80211g"



# choix des noeuds physiques
# attention à ce que les noeuds soient bien disponibles au moment de la réservation
tb-fix-node $nodew1 pcwf164
tb-fix-node $nodew2 pcwf162
tb-fix-node $nodew3 pcwf148
tb-fix-node $nodew4 pcwf142


# choix d'autre option
tb-set-lan-setting $lan0 "channel" 6
tb-set-lan-setting $lan0 "mode" "adhoc"




# Choix de l'OS dédié au WiFi sur la plateforme : Fedora Core 4
# Lorsqu'on veux un OS compatible avec le WiFi le choix est très réduit
# Fedora 4 est sortie en Juillet 2005 ...
tb-set-node-os $nodew1 FC4-WIRELESS
tb-set-node-os $nodew2 FC4-WIRELESS
tb-set-node-os $nodew3 FC4-WIRELESS
tb-set-node-os $nodew4 FC4-WIRELESS


# Définition manuelle des routes
# Notre architecture de chaîne étant un peu particulière
# Il est nécessaire de rentrer des tables de routage à la main
# Mais il est aussi possible de les configurer une fois les noeuds réservés
# Grâce aux commandes système habituelles.
$ns rtproto Manual
$nodew1 add-route nodew2 nodew2
$nodew1 add-route nodew3 nodew2
$nodew2 add-route nodew3 nodew3
$nodew2 add-route nodew1 nodew1
$nodew3 add-route nodew1 nodew2
$nodew3 add-route nodew2 nodew2

# Tout est prêt pour commencer =)
# Il est également possible de spécifier des temps
# Ces temps peuvent servir pour arrêter l'expérience, après une certaine durée par exemple
$ns run

Présentation du forum

Le forum, que l'on trouvera ici, est également assez utile pour trouver réponse aux questions que l'on pourrait se poser sur le déroulement des tests. Cependant, il n'est pas très actif, il ne semble pas très utilisé. Il contient pourtant beaucoup d'informations intéressantes, et n'est donc pas dénué d'intérêt.

IV Avantages

Bon, finies les présentations formelles, je vais maintenant vous présenter ce que je considère comme étant de véritables avantages à utiliser ce genre de plateforme de test. Puis, dans la section suivante, je ferai de même concernant les inconvénients.

Gestion de matériel

L'utilisation de ce genre de plateforme prévient de toute gestion de matériel, ce qui constitue notamment un certain confort financier. Comme on l'a vu précédemment, l'action nécessitait 4 machines. Et encore, ce n'était qu'un début ! Pour celle-ci, il en fallait en réalité 5. Pour être plus précis, pour une chaîne de taille n, il fallait n+(n-1) machines : ça devient vite ingérable si on doit les entretenir et les configurer à la main ! De plus, trouver autant de machines identiques (pour n'introduire aucun biais) peut s’avérer compliqué. Avec une plateforme comme Emulab, ce genre de problèmes n'apparaît plus. Même si une machine physique vient à tomber en panne, il suffit d'en choisir une autre parmi les machines disponibles et ayant les même caractéristiques recherchées.

Gain de place

Ce genre d'environnement permet également d'accéder à un certain dimensionnement spatial. Le fait, pour le cas du WiFi, d'avoir accéder à une carte permet de choisir la distance entre les noeuds, et donc de maîtriser, dans une certaine mesure, la topologie physique du réseau.
Dans le cas des réseaux filaires, en plus d'éviter le coût d'achat des machines (et des équipements intermédiaires !), l'utilisation de testbed permet de ne pas avoir à se soucier du stockage des machines. Les laboratoires de recherche peuvent vite devenir très petit dès que l'on parle de déployer de certain nombre de machines. Il se pourrait même que l'on se voit contraint d'aller faire certaines expérimentations en extérieur ! (Oui oui ça sent encore une fois le vécu, je sais ...)

Environnements homogènes et hétérogènes

Étant donné qu'il est possible dans le script de réservation de spécifier un type de machines par noeuds que l'on souhaite réserver, il est également possible de créer l'environnement de test dont on a besoin. Il est possible de déployer un ensemble très homogène avec le même OS tournant sur les mêmes configurations matérielles. Mais il est également possible de créer des choses bien plus hétérogènes : il est tout à fait possible de combiner les différentes versions de différents OS tournant sur des machines différentes entre elles... C'est quelque chose de très intéressant si l'on veut étudier le comportement d'une solution dans des cas très différents. Ce point peut être assez compliqué à atteindre dans un laboratoire sans un certain budget.

Outils de monitoring

La plateforme propose également de fournir des outils de surveillance du réseau et de produire des logs, de même qu'il est possible de soumettre le réseau à des charges de manière automatique, à partir du script décrivant la topologie du réseau. Cependant, je suis assez peu familier avec ces mécanisme: je n'ai utilisé que des outils que je connaissais bien pour générer du trafic et des traces réseau.

V Désavantages

Bon, présenté comme ça, je suis sûr que ça fait très envie comme solution pour vos expériences. Cependant, il y a quand même (selon moi) un certain nombre d'inconvénients à utiliser un testbed de ce genre. Si durant mon stage, on a fini par préférer un environnement "maison", ce n'est pas pour rien.

Architectures partagée

Le testbed reste avant tout un environnement partagé par plusieurs utilisateurs. Il est donc assez difficile d'avoir conscience de l'état du réseau entre les machines. Même si virtuellement on ne voit rien passer sur les liens, il est très facile d'imaginer des situations où plusieurs expériences sont en cours simultanément, et partagent des portions de réseau. Il devient alors (pour moi en tout cas) assez difficile de faire confiance aux résultats. Comme savoir si un lien est réellement saturé ou pas ? De même, il est compliqué (voir impossible ?) de contrôler quels sont les équipements intermédiaires qui sont traversés par notre trafic, et donc de tester certaines fonctionnalités notamment présentes sur certains switchs. Encore une fois, je ne me suis pas beaucoup intéressé à la partie filaire, donc ce genre de fonctions me sont peut-être simplement inconnues.
Pour vous donner une idée d'une partie de la topologie filaire, je vous laisse là une jolie carte



Souplesse

Le manque de souplesse peut être compliqué à gérer. En effet, il n'est pas vraiment possible de faire des petits tests jouets "juste pour voir". Ou alors, cela implique de garder des noeuds réservés alors que l'on en aura une utilisation limitée. (C'est pas sympa) De plus, dans le cas du WiFi la topologie physique peut poser problème. Il est impossible déplacer les noeuds, donc il peut être compliqué d'obtenir ce que l'on souhaite car la plateforme est assez active. Certaines mesures peuvent donc aussi manquer de précision. Comment calculer un débit entre deux machines en fonctions de la distance entre elles ? Pas facile d'obtenir des valeurs correctement distribuées dans l'espace.

Choix du système

Le choix du système ... On en a déjà un peu parler plus haut. Emulab propose un choix d'OS assez large, différentes versions de Linux, de BSD et même de Windows. En revanche, pour une raison qui m'échappe encore aujourd'hui (et oui j'ai vérifié la documentation avant d'écrire ça), lorsque l'on souhaite effectuer des expérimentations sur des noeuds communicant en Wifi, le choix du système se restreint énormément. Le seul OS qui est annoncé comme étant compatible avec cette fonctionnalité est Fédora Core 4. Je n'ai rien contre Stentz, mais c'est un peu dépassé. Il est difficile de se rendre compte du comportement de certains phénomènes avec des systèmes un peu vieux, notamment la gestion des politiques de queuing au niveau 2

Interférences

Et enfin, pour clore cette belle liste de soucis pouvant survenir, je citerai ... les interférences ! C'est une chose à laquelle nous n'avions pas pensé lors des premiers tests. Cependant, étant une plateforme de test, d'autres expériences sont toujours en cours : il est donc impossible d'avoir un canal sans interférences. Dans un set-up "maison", il est également difficile de n'avoir aucune interférence, mais il est facile de réaliser qu'un réseau utilisé "normalement" est moins actif, et donc moins gênant que des réseaux soumis à des tests. Il est donc compliqué de valider ou de s'approcher de modèles théoriques simples, mais ce problème n'est pas vraiment intrinsèque à la plateforme ....

Conclusion

Je crois que la conclusion est plutôt évidente après lecture de cette page. Les testbeds de ce genre peuvent apporter un vrai soutien à la recherche et aux tests divers et variés en ôtant un grand nombre de contraintes. Cependant il faut rester conscient du fait qu'il existe un grand nombre de freins et d'éléments à prendre en compte.

De plus, il est nécessaire, avant l'utilisation d'une plateforme, d'avoir bien défini l'ensemble des besoin de notre expérimentation afin de s'assurer qu'ils soient compatibles avec les services offerts avec telle ou telle plateforme =)